Reverts #317, so it should default back to 4 threads

This basically creates a singleton PostgresDBClient instance, which holds the Sqlalchemy engine.

“the engine is thread safe yes. individual Connection objects are not. we try to describe this at Working with Engines and Connections — SQLAlchemy 2.0 Documentation”

A new session uses an available connection (from the connection pool), so threads (e.g., those created from API calls) will not share a connection.

Our pool size is 20 – what happens when max sqlalchemy pool size is reached?

Google’s AI states:

Requests are queued: Any new requests for a database connection are placed in a queue, waiting for a connection to become available.

Timeout begins: SQLAlchemy starts a timeout period (defaulting to 30 seconds, but configurable) to see if a connection is released back into the pool.

Connection timeout error: If a connection doesn't become available within the timeout period, an exception (e.g., TimeoutError) is thrown, indicating a connection timeout.

SQLAlchemy connection pooling, what are checked out connections? : “If all the connections are simultaneously checked out then you can expect an error (there will be a timeout period during which SQLAlchemy waits to see if a connection gets freed up; this is also configurable).”

What's the reason for these changes? Because the db_session from the test fixture (the second parameter to test_retrieve_with_scores) is different from the db_session generated by retrieve_with_scores?

Yes. There's some identifier in the chunk instances that is specific to the db_session, so those identifiers are different and cause the assertion to fail. Otherwise the chunks are identical.

Gotcha. I think the identifier here is the literal address in memory: under the hood, SQLAlchemy ensures that if you retrieve the same row back in the same session, it creates only a single instance of the object in memory so you can do things like (psuedocode):

with some_session:
    # in this call SQLAlchemy creates a new instance of the Chunk class and returns that
    chunk_1 = some_session.select(chunk_id="abc").first()
    
    # in this call SQLAlchemy will recognize that it already has an instance of the Chunk class for this row, so it will return that Chunk
    chunk_2 = some_session.select(chunk_id="abc").first()
    assert chunk_1 == chunk_2 # these are literally the same object in memory